This invention relates to the fields of computer systems and computer security. More particularly, methods and apparatus are provided for protecting against CSRF (Cross-Site Request Forgeries) by processing a stream of content as it is served and inserting special tokens, and examining a follow-on data request to ensure it possesses a token.
A cross-site request forgery is a type of computer attack in which an illegitimate data or application request is accepted at a targeted website or application because it contains a valid session cookie. Typically, the perpetrator of the attack tricks an authorized user—the user to whom the valid cookie was issued—into activating a reference (e.g., a hyperlink) at a site other than the target site, such as at a site operated by the perpetrator, and that reference generates the request. In accordance with normal HTTP (Hyper Text Transport Protocol) processing, the authorized user's browser will automatically add the cookie to the request when it is submitted to the target site.
A CSRF may therefore allow a malicious actor to modify data they otherwise could not modify, or to perform some action that ordinarily they could not (e.g., create a user account, change a password). For example, the valid user may be authorized to access private or privileged information, such as personnel records, social security numbers and so on. By hijacking the valid user's session cookie, the perpetrator of the CSRF may be able to manipulate such information.
Traditionally, a website is protected against CSRFs by requiring an additional hidden set of data (beyond just a session cookie) in order to accept a content request as legitimate. For example, the additional data may be generated as part of a web form, an HTML link, an HTTP header, a scripted request or other set of content that can be manipulated to initiate a new request.
When the user's browser receives and acts on the content to initiate a request (e.g., by filling out a form, by activating a link), the request is accepted only if it contains the data that was embedded in the content. Because a third party (e.g., an initiator of a CSRF attack) would not receive the hidden data, and the browser does not automatically include it (like a cookie), it could not create a properly formatted request, and thus the target site would reject the third party's request.
However, for this form of CSRF protection to work, the hidden data must be injected into every interface or control that provides access to content that is to be protected. Templates for dynamically generating the interfaces could be manually modified to insert the data, but then the additional data may be static (instead of differing for different requests) and could become known, in which case this security feature could be compromised.
Instead, the additional data may be added by parsing each relevant web document (e.g., each HTML document that provides access to protected content) as it is generated by a server, storing a representation of the web document in memory (e.g., as a DOM or Document Object Model tree), traversing that representation, modifying the document's structure to include the additional data, and then generating new HTML code to be served to the requester.
Reconstructing and modifying the document after it has been served, but before it can be delivered to a destination user, necessarily entails delay and inefficiency. In particular, this attempted solution requires additional processing for every page of HTML, to construct a DOM or other model, to parse it to identify a location at which to insert the data, and to assemble a new HTML page to be served. The consumption of processor time and the use of memory to store the document model, which occurs every time a user requests access to protected content, may have a negative effect on a server's performance and a user's experience. The content is likely to be delayed in getting to the user because it cannot be forwarded until the parser has reconstructed the entire document.
In addition, the parsing process is likely to alter the HTML in ways other than simply adding the additional data. For example, parsing and reconstruction of the HTML code may reduce (or increase) whitespace, change a font or font size, change case (e.g., uppercase to lowercase or vice versa) and/or make other alterations. Even a subtle change in the HTML may cause an application that operates on the code to act differently or to present the HTML differently to a user.
In addition, an HTML parser (or a parser that operates on other markup language) expects to receive well-formed code, and may not be able to handle code that contains even a minor error. An error in a page of HTML content may cause the parser to operate incorrectly or to fail to operate on the content, thereby preventing a user from receiving the content or from initiating a follow-on request (e.g., because the additional data could not be inserted as required).
Thus, this method of protecting against a CSRF may cause changes in a legitimate user's experience, or may even cause content to be presented incorrectly or not be presented at all.